Server, information communication terminal, product sale management method, and storage medium and program transmission apparatus therefor

ABSTRACT

A product retail sales management server for managing the retail sales of a product across a communication network comprises: a retail sales management module for managing the retail sales of the product; a price update module  13  for dynamically setting the price of the product in accordance with rules and the retail sales state of the product and in accordance with the actual retail sales state of the product when managed by the retail sales management module; and an acceptance module  11  for, upon the receipt of an information request via the communication network, furnishing a request transmission source with the information concerning the product and the price of the product, set by the price update module at the time the information request is received.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a retail sales management systemfor use when products are sold via a communication network.

[0003] 2. Discussion of Related Art

[0004] Electronic commerce, involving the retail sales of products andthe contracting out of services using communication networks, such asthe Internet, has become a popular and wide spread addition to theretail sales business field. An intending purchaser, when availinghimself or herself of the conveniences afforded by electronic commerce,generally selects a desired product, or a service, by referring toproducts for sale, or services to be provided, that are listed on acomputer screen, enters his or her name, address and telephone number,along with a payment method, and transmits these data to a retailer.This is all that is required of the purchaser; all other proceduresassociated with a purchase are handled by the retailer.

[0005] The price for a product or the charge for a service is generallyset by a retailer. At this time, the retail price is normally determinedby adding a profit margin to the actual expenses involved in themanufacture of a product, or in the provision of a service. Further,when determining a price, the popularity a product enjoys among users,and user product evaluations may be taken into account.

[0006] There are retailing methods, such as auction sales, where buyerstake the initiative in setting prices. In such a case, however, sincethe buyers compete with each other and bid up the price of a product,the final price paid may far exceed that which most consumers wouldregard as appropriate. And since an auction sale is more appropriatewhen the number of intending purchasers exceeds the available supply ofa product, it is not suitable for general trading.

[0007] According to one method whereby the retail price of a product isdynamically established, for a product such as a computer program, theemployment frequency (the number of activations, or the employmentperiod) is recorded and measured, and when a predetermined value isreached, the payment of a charge is requested. According to anothermethod, when a specific time has elapsed following the start of a sale,the retail prices of some subject products are reduced. However, theseretailing methods do not immediately and directly reflect an evaluationsuch as is acquired when a product has been tested on the market and hasbeen compared with other, similar products.

[0008] During the exchange of data across a communication network, userevaluations of content to be provided may be fed back to an intendingpurchaser. For example, the number of times the content was accessed, ora user evaluation may be supplied as a reference item to facilitate theselection of content. Or, the content may be ranked in accordance withits evaluation or employment frequency, and thereafter presented to anintending purchaser.

[0009] However, content evaluation is merely provided as referencematter to be considered when a choice is made, and is not used as abasis for the setting of a price for a product (content).

[0010] As is described above, according to the conventional retail salesmethod, when a retailer sets a price for a product or a charge for aservice, a value attributable the popularity of the product or theservice with users, and how they evaluate it may be added to the price.However, when the popularity of a product or service or the userevaluation of it fluctuates over time, a great deal of labor must bedevoted to immediately, and frequently, changing the retail price toreflect marketing realities.

[0011] However, if a price is set each time there is a variation in thepopularity or in the user evaluation of a product or service, a lowerprice can be set for an unpopular product or service to increase itsmarketing competitiveness, or a higher price can be set for a popularproduct or service to increase the net profit.

[0012] Further, conventionally, when a retailer sets a retail pricewhile taking into account the popularity or the evaluation of a productor a service, only the current popularity or evaluation are taken intoconsideration when the price is selected. However, if along with analtered retail price information were provided concerning trendsaffecting price changes (e.g., how the price will subsequently bechanged), such information would assist a user in appropriately timingthe purchase of a product or the selection of a service.

[0013] As is described above, according to the conventional method fordynamically setting the retail price of a product, the price of afrequently employed product is increased and the price of a lessfrequently employed product is reduced. But the conventional method cannot flexibly assign a new retail price consonant with a change in thepopularity or in the overall user evaluation of a product or a service.

[0014] It is, therefore, one object of the present invention to providea retail sales management system that, consonant with the level ofpopularity or the user evaluation of a product or service, dynamicallysets a retail price for a product or a charge for a service.

SUMMARY OF THE INVENTION

[0015] To achieve the above object, according to the present invention,a server for managing the retail sales of a product across acommunication network comprises: retail sales state management means formanaging the retail sales state of the product; price setting means fordynamically setting the price of the product in accordance with rulesand the retail sales state of the product and in accordance with theactual retail sales status of the product when managed by the retailsales state management means; and product information provision meansfor, upon the receipt of an information request via the communicationnetwork, furnishing a request transmission source with the informationconcerning the product and the price of the product, set by the pricesetting means at the time the information request is received.

[0016] According to the present invention, a product is any itemtargeted for business trading (sales) across a communication network.Therefore, in addition to prices for general goods and digital content,the present invention can be applied for the dynamical setting of acharge for a service.

[0017] Further, according to the present invention, a server may also beprovided that does not include the product information provision meansand that dynamically sets retail prices consonant with the actual retailsales states of products.

[0018] The server further comprises: price trend information provisionmeans for generating, in accordance with the actual retail sales stateof the product, information concerning trends affecting the changes ofthe price of the product, and for furnishing the information to theinformation request transmission source.

[0019] This configuration is preferable because an intending purchaserof a product can refer to the information concerning trends affectingthe changes of the price of the subject product, and can acquire anappropriate timing for the purchase of the product.

[0020] The information concerning the trends affecting the changes ofthe price of the product can be arbitrarily set, using content based onthe number of products sold, such as “how much the price will beincreased after how many more products are sold”, content based on atime element, such as “how much the price will be reduced at what time”,or content based on a rank provided in accordance with the popularity orthe user evaluation of a product, such as “how much the price will beincreased (or reduced) when the rank is incremented (decremented) byone”.

[0021] Specifically, a method for setting a price in accordance with thenumber of products sold can be employed to increase the profit providedby a product that is selling well and for providing a competitive priceprovided by a product that is not selling well. For example, the pricesetting means can set a price for the product by using rules, based onthe retail sales state of the product, according to which the price isincreased as the number of product units sold rises or decreased as thenumber of product units sold falls.

[0022] Furthermore, according to the present invention, a server forcharging for and providing digital content via a communication networkcomprises: sales state management means, for managing the sales state ofthe digital content; price setting means, for dynamically changing acharge for accessing the digital content in accordance with rules andthe sales state of the digital content and in accordance with the salesstate of the digital content, which is managed by the sales statemanagement means; and information provision means for presenting to aninformation request transmission source, upon the receipt of aninformation request via the communication network, informationconcerning the digital content and the charge for accessing the digitalcontent that is set by the price setting means at the time theinformation request is received.

[0023] A server can be provided that does not include the informationprovision means and that dynamically sets the access charge inaccordance with the actual sales state of the digital content.

[0024] The server further comprises: price trend information provisionmeans, for generating, in accordance with the sales state of the digitalcontent, information concerning trends affecting the changing of thecharge for accessing the digital content and for furnishing theinformation to the information request transmission source.

[0025] This configuration is preferable because a user who accesses anddownloads the digital content can refer to the information concerningthe trends affecting the price of the subject product, and can acquirean appropriate timing for accessing the digital content.

[0026] As well as for a general product, information concerning trendsassociated with the changing of an access charge, such as the contentsbased on an access count, the contents based on a time element, or thecontents based on a rank awarded in accordance with the popularity orthe user evaluation of a product, can be arbitrarily set.

[0027] The price setting means sets the charge for accessing the digitalcontent in accordance with rules and the sales state of the digitalcontent and according to which the charge for an access is increasedwhen the number of accesses of the digital content rises or is reducedwhen the number of accesses falls.

[0028] The price setting means sets the charge for accessing the digitalcontent in accordance with rules, which is based on the sales state ofthe digital content, according to which the charge for an access isincreased when the rank awarded the digital content, which is consonantwith the popularity or the evaluation of the digital content, isincremented, or the charge for an access is reduced when the rankawarded the digital content is decremented.

[0029] According to the present invention, an information communicationterminal is provided, for accessing a product retail sales managementserver across a communication network and for purchasing a productoffered by the server, whereby an information request is issued to theserver in order to obtain information concerning the product and theprice of the product; whereby the information concerning the product andthe price of the product, and information concerning trends affectingthe changes of the price are received after the server has accepted theinformation request; and whereby, when a user has examined theinformation, as needed, and has determined to purchase the product, apurchase request to that effect is transmitted to the server.

[0030] Further, according to the present invention, a product retailsales management method, for managing the retail sales of a product inaccordance with a purchase request that is issued, via a communicationnetwork, by a server connected thereto, comprises the steps of: managingthe retail sales state of the product; dynamically setting the price ofthe product in accordance with rules and the retail sales state of theproduct and in accordance with the actual retail sales status of theproduct; and furnishing information concerning the product upon thereceipt of an information request via the communication network, andfurnishing the price set for the product at the time the informationrequest is accepted. The product retail sales management method furthercomprises, after the step of furnishing the price of the product, a stepof accepting a purchase request for the product that is issued after theinformation concerning the product and the price of the product havebeen provided.

[0031] The product retail sales management method of the inventionfurther comprises the steps of: generating, upon receipt of theinformation request, information concerning trends affecting the changesof the price of the product in accordance with the retail sales state ofthe product. At the step of furnishing the information concerning theproduct and the price of the product, the information concerning thetrends affecting the changes of the price of the product can also befurnished.

[0032] According to the present invention, a storage medium can beprovided on which reading means of a computer stores a computer-readableprogram that permits the computer to perform the processes thatcorrespond to the steps of the product retail sales management method.

[0033] In addition, a program transmission apparatus can be providedthat comprises: storage means for storing the program; and transmissionmeans for reading, from the storage means, and transmitting the program.

[0034] This configuration is preferable because a computer that executesthe program can perform product retail sales management, includingdynamically setting the price of a product in accordance with its retailsales state of the product.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0035]FIG. 1 is a diagram for explaining the general configuration of aretail sales management system according to the embodiment.

[0036]FIG. 2 is a diagram for explaining the structure of a productretail sales management server according to the embodiment.

[0037]FIG. 3 is a diagram showing an example structure for an initialsetup table used for the embodiment.

[0038]FIG. 4 is a diagram showing an example structure for a pricedetermination policy table used for the embodiment.

[0039]FIG. 5 is a diagram showing an example structure for a currentprice table used for the embodiment.

[0040]FIG. 6 is a diagram showing an example structure for a price trendtable used for the embodiment.

[0041]FIG. 7 is a diagram showing an example structure for a retailsales history table used for the embodiment.

[0042]FIG. 8 is a flowchart for explaining the operation of anacceptance module according to the embodiment.

[0043]FIG. 9 is a flowchart for explaining the operation of a retailsales management module according to the embodiment.

[0044]FIG. 10 is a flowchart for explaining the operation of a priceupdate module according to the embodiment.

[0045]FIG. 11 is a flowchart for explaining the operation of a pricetrend update module according to the embodiment.

[0046]FIG. 12 is a diagram showing an example input screen used for theembodiment.

[0047]FIG. 13 is a diagram showing the state of the input screen after apredetermined time has elapsed since the state shown in FIG. 12.

[0048]FIG. 14 is a diagram showing the initial states of the respectivetables for an example operation according to the embodiment.

[0049]FIG. 15 is a diagram showing tables in which the states of thecontents in FIG. 14 have been changed.

[0050]FIG. 16 is a diagram showing tables in which the states of thecontents in FIGS. 14 and 15 have been changed.

[0051]FIG. 17 is a diagram showing the initial states of the respectivetables for another example operation according to the embodiment.

[0052]FIG. 18 is a diagram showing tables in which the states of thecontents in FIG. 17 have been changed.

[0053]FIG. 19 is a diagram showing tables in which the states of thecontents in FIGS. 17 and 18 have been changed.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0054] Preferred embodiments of the present invention will now bedescribed in detail while referring to the accompanying drawings.

[0055]FIG. 1 is a diagram for explaining the general configuration of aretail sales management system according to the embodiment. In thisembodiment, the retail sales management system can be used to providevarious products and services; however, to simplify the explanation,general goods and services are collectively described as products, andthe retail sales of digital content, such as music, is especiallyemployed as an example. Further, the Internet is employed as acommunication network.

[0056] In FIG. 1, the retail sales management system for this embodimentis carried out by a product retail sales management server 10 for theretail sales of products across the Internet. The product retail salesmanagement server 10 receives a request from a user terminal 30, aclient, returns an input screen file as an interface, and accepts fromthe user terminal 30 the entry of data concerning the purchase of aproduct.

[0057] In FIG. 1, when the user terminal 30 issues a product informationrequest (101) to the product retail sales management server 10, theproduct retail sales management server 10 returns, to the user terminal30, an input screen file (102) in which is written informationconcerning the product for sale, and the user terminal 30 displays aninput screen based on the input screen file (102) that is received fromthe product retail sales management server 10. On the input screen,information concerning the product for sale and the current retail pricefor the product are displayed.

[0058] Then, the user designates a desired product by referring to theinput screen, enters necessary information, and uses the user terminal30 to transmit a purchase determination command (103) to the productretail sales management server 10. Upon the receipt of the command, theproduct retail sales management server 10 returns, to the user terminal30, a notification (104) confirming the reception of the purchaseprocedures.

[0059] The product purchase processing is the same as the electroniccommerce processing used to purchase an ordinary product via theInternet. In this embodiment, it should be noted that, since the retailprice of the product is dynamically set, when the product information istransmitted as the input screen file (102) the retail price of theproduct is defined as the current price. Therefore, when the product isto be purchased after a specific time has elapsed since productinformation was furnished, the processing for the provision of thelatest retail price of the product can be added. That is, the userterminal 30 transmits a product purchase request (105) to the productretail sales management server 10, and receives from the product retailsales management server 10 the latest retail price (106). If apredetermined time has elapsed since the product retail sales managementserver 10 received the purchase determination command (103), the server10, instead of accepting the purchase procedures, may return the latestretail price (106).

[0060] In this arrangement, the functions of the product retail salesmanagement server 10 can be performed by a web server, and the inputscreen is prepared as a web page. Then, when at the user terminal 30data is entered in the web page, the product purchase procedures areaccepted.

[0061] Further, in this case, the user terminal 30 uses a web browser todisplay the web page.

[0062]FIG. 2 is a diagram for explaining the configuration of theproduct retail sales management server 10. In FIG. 2, an acceptancemodule 11 accepts a product information request (101) from the userterminal 30. A retail sales management module 12 manages the history ofthe retail sales of the product. A price update module 13 manages theretail price of the product. And a price trend update module 14 managesthe trends associated with the changing of the retail price of theproduct.

[0063] A database 20 is used to manage the product and its sale, and aninitial setup table 21, a price determination policy table 22, a currentprice table 23, a price trend table 24, a retail sales history table 25,and a ranking table 26 are stored in the database 20.

[0064]FIG. 3 is a diagram showing an example structure for the initialsetup table 21.

[0065] Various information for determining the price of a product isstored in the initial setup table 21. In the example in FIG. 3, aproduct ID, a dependency element for determining the retail price, thelowest price, the highest price and the currency unit are stored in theinitial setup table 21. The dependency element is used to determine theprice of a product and a change in the price. The number of sales inFIG. 3 indicates that the price will be changed when a predeterminednumber of product sales have been recorded. That is, since digitalcontent, such as music or video data, is downloaded once every time itis sold, the price is changed in accordance with the sales count. For aproduct or a service other than digital content, the price can bechanged in accordance with the number of units that have been sold orthe number of times the service has been provided. In addition to thesales count in FIG. 3, the dependency element can be the retail salefrequency, which indicates the number of retail sales (units) processedin a specific period of time, or a ranking based on an arbitraryconcept, such as a retail sales ranking or a popularity ranking based onpredetermined data. Since for the sale of music, there is a web sitethat provides rankings representative of the popularity of musicalpieces, ranking information obtained by tying up with the site can beemployed as the dependency element.

[0066] The lowest price and the highest price are set so that the priceof the product will not fall below or rise above a specific value. Whena certain product is especially popular and purchase requests areconcentrated on that product, if the number of purchases is set as thedependency element, the price of the product will increase endlessly.However, when the price has increased until it is too high to beappropriate for the product, the number of purchase requests will fall,and this is not an acceptable condition for either the seller and thebuyers. On the other hand, when the popularity of a specific product islow and the no trading history has been accumulated for it, a pricewhereat there is neither a loss nor a profit must be set based on themanufacturing cost of the pertinent product. Therefore, a reasonableprice range should be determined for the product. However, these dataare not requisite, and one or both of the lowest and the highest pricesmay not be set as desired by the seller.

[0067] Since the entry for the currency unit is set while taking intoaccount the convenience it offers for trading, this is an arbitrarysetting.

[0068]FIG. 4 is a diagram showing an example structure for the pricedetermination policy table 22.

[0069] In the price determination policy table 22, the policy fordetermining the price of a product is set for a corresponding dependencyelement in the initial setup table 21. For example, when the number ofretail sales is set as the dependency element in the initial setup table21, a retail sales count dependency policy was set, such as “increasethe price by 10 yen when there have been twenty sales of the product”,or “reduce the price by 10 yen when there have been no sales of theproduct for 120 minutes”. Similarly, when the ranking is set as thedependency element of the initial setup table 21, a ranking dependencypolicy is established, such as “increase the price by 10 yen when therank is incremented by one”, or “reduce the price by 10 yen when therank is decremented by one”. Further, when retail sales frequency is setas the dependency element for the initial setup table 21, a retail salesfrequency dependency policy is entered, such as “increase the price by10 yen when the retail sales frequency (the number of retail sales(units) handled in a predetermined period) is increased by 10%” or“reduce the price by 10 yen when the retail sales frequency is reducedby 20%”. It should be noted that the parameters (the count, the ranking,the retail sales frequency, etc.) in the policy described above, and theunit for the price change (10 yen) can be arbitrarily established.

[0070]FIG. 5 is a diagram showing an example arrangement for the currentprice table 23.

[0071] The product ID and the current price of the product are stored inthe current price table 23. In addition, the currency unit for the priceis stored as needed, e.g., when a purchase request originating in aforeign country is accepted via the Internet.

[0072]FIG. 6 is a diagram showing an example structure for the pricetrend table 24.

[0073] A condition for a next price change is stored in the price trendtable 24 consonant with the dependency element in the initial setuptable 21. For example, the number of retail sales is set as thedependency element in the initial setup table 21, and a condition suchas “increase the price of the product after five more sales (Rest_C 5)”or “last time the product was sold (Last Access C)” is set as aparameter until the price is changed. Further, when the retail salesfrequency is set as the dependency element in the initial setup table21, a condition such as “increase the price of the product when it issold five or more times a day (Freq_C 5)” is set as a parameter untilthe price is changed. In addition, the time condition can be set as aparameter, and a condition such as “maintain the current price until12:59 in the afternoon (Next_T 12:59 PM)” can be designated. Thenumerical value for the count, the frequency and the time for eachcondition can be arbitrarily set.

[0074]FIG. 7 is a diagram showing an example arrangement for the retailsales history table 25.

[0075] The retail sales time and the price of the product at that timeare stored in the retail sales history table 25. The total number ofretail sales of the product is also managed in this table. And inaddition, ID information for purchasers of the product may be stored inorder to provide after sale service.

[0076] When the ranking information is set as the dependency element inthe initial setup table 21, a rank (the retail sales count rank orpopularity rank) corresponding to the dependency element is stored inthe ranking table 26. In this embodiment, a site for obtaining theaggregate for the ranking may be provided for the product retail salesmanagement server 10 that provides a product retail service, and uniqueranking may be determined. Or, the information for ranking performed byanother web site is obtained, depending on a product, and may be storedin the ranking table 26. When the product is music or video, theinformation is obtained from the site established to provide rankingsfor the popularity of music pieces or films, so that the price of theproduct can be set based on more general ranking information.

[0077] The operations of the individual modules will now be described.First, the operation of the acceptance module 11 will be explained.

[0078]FIG. 8 is a flowchart for explaining the processing performed bythe acceptance module 11 in FIG. 2. When the acceptance module 11receives a product information request (see 101 in FIG. 1) from the userterminal 30 (step 801), the acceptance module 11 examines the currentprice table 23 to obtain the current retail price of the requestedproduct (step 802). Then, the acceptance module 11 inquires of the pricetrend update module 14 the trends associated with the changing of theprice of the product (step 803). The acceptance module 11 prepares theinput screen for the purchase of the product in accordance with thecurrent retail price obtained at step 802 and the information concerningthe price change trends received from the price trend update module 14at step 803. And the file for the input screen (see 102 in FIG. 1) istransmitted to the user terminal 30 (step 804). A detailed descriptionof the input screen will be given later.

[0079] During this processing, the acceptance module 11 examines theprice trend table 24 to directly obtain information concerning the pricechange trends, but also inquires of the price trend update module 14 thetrends associated with the changing of the price. This is done becausesince the information for the trends associated with the changing of theproduct price varies in accordance with the retail sales state of theproduct and the elapsed time, the user terminal 30 should be providedthe latest information.

[0080] When the user terminal 30 receives the data file for the inputscreen, it then displays the input screen. Thereafter, to purchase adesired product, a user enters data on the input screen displayed by theuser terminal 30, and uses the user terminal 30 to transmits a purchasedetermination command (see 103 in FIG. 1). At this time, since at theleast, a specific time will have elapsed between the time the inputscreen file was received and the time the purchase determination commandwas issued, the retail price of the product may have changed since theinput screen file was received. In this case, when the product retailsales management server 10 accepts the purchase determination command(corresponding to step 801), before finally accepting the purchaserequest, the server 10 may perform the processes at steps 802 to 804 andtransmit the latest retail price to the user terminal 30 (see 106 inFIG. 1).

[0081] A script may also be displayed in the input screen filetransmitted to the user terminal 30 in order to request the periodictransmission of the latest price and the price change trends, so thatfor updating, the price and the price change trends are periodicallytransmitted by the product retail sales management server 10.

[0082] The processing performed by the retail sales management module 12will now be described.

[0083]FIG. 9 is a flowchart for explaining the processing performed bythe retail sales management module 12.

[0084] The retail sales management module 12 monitors the operation ofthe acceptance module 11. When the retail sales management module 12detects the receipt by the acceptance module 11 of the product purchasedetermination command and the acceptance of the purchase procedures(step 901), the retail sales management module 12 updates the retailsales history table 25 (step 902). Then, in order to determine whetherthe price should be changed for this retail sale, the retail salesmanagement module 12 calls up the price update module 13 and shifts theprogram control to it. Thereafter, the processing is terminated (step903).

[0085] The operation of the price update module 13 will now bedescribed.

[0086] The price update module 13 operates periodically, or inaccordance with a call by the retail sales management module 12, andupdates the current price table 23.

[0087]FIG. 10 is a flowchart for explaining the processing performed bythe price update module 13.

[0088] The price update module 13 is activated when it is called up bythe retail sales management module 12, or when a predetermined starttime is reached (step 1001). Then, a policy PO is obtained from theprice determination policy table 22, and a change condition C, which iseffective until the retail price of the product is changed, is acquiredfrom the price trend table 24 (step 1002). The information required todetermine whether the current price table 23 must be updated is alsoacquired in accordance with the policy PO and the change condition C(step 1003). The information required for the determination differs,depending on the definition of the policy PO.

[0089] When the policy PO for changing the price in accordance with thenumber of units sold is defined, information concerning the number ofproduct units sold must be obtained from the retail sales history table25 in order to ascertain how many units have been sold. Further, whenthe policy PO according to which the price is changed as time elapses isdefined, the current time must be obtained from the system.

[0090] In this manner, required information is acquired in accordancewith the contents of the policy PO. When all information that it seemsmay be used for the determination has been acquired, only necessaryinformation is employed in accordance with the contents of the policyPO.

[0091] Then, the obtained information and the policy PO are employed todetermine whether the current price table 23 should be updated (step1004). Then, when the policy PO definition is that the price must bechanged in accordance with the number of retail sales unit, and thenumber of retail sales unit at which the price must be changed isreached, it is ascertained that the current price table 23 must beupdated.

[0092] When it is ascertained that an update of the current price table23 is necessary, thereafter, a new price based on the policy PO iscalculated, and the price of the product in the current price table 23is updated (steps 1005 and 1006).

[0093] When the current price table 23 has been updated in this manner,or when an update is not required, the price trend update module 14 iscalled up and program control is shifted thereto. The processing isthereafter terminated (step 1007). When the current price table 23 isupdated and the price of the product is changed, the price trend table24 must be changed in accordance with the new price. Even if the currentprice table 23 need not be updated, a condition that is effective untilthe price has been changed may be altered when the product has been soldor when a predetermined time has elapsed. Therefore, the price trendupdate module 14 determines whether the condition is changed, and ifnecessary, updates the price trend table 24.

[0094] The operation of the price trend update module 14 will now bedescribed.

[0095]FIG. 11 is a flowchart for explaining the processing performed bythe price trend update module 14.

[0096] The price trend update module 14 is activated upon the receipt ofthe inquiry from the acceptance module 11 (see step 803 in FIG. 8) or inaccordance with the call issued by the price update module 13 (see step1007 in FIG. 10) (step 1101). Then, the price trend update module 14obtains, from the price determination policy table 22, the policy PO fordetermining the retail price of the product, and acquires from the pricetrend table 24 the change condition C that is effective until the retailprice of the product is changed (step 1102).

[0097] In accordance with the policy PO and the change condition C, theprice trend update module 14 also obtains the information needed todetermine whether the price trend table 24 should be updated (step1103). The information required for the determination differs, dependingon the definition provided by the policy PO.

[0098] When the policy PO for changing the price in accordance with thenumber of retail sale units is defined, the condition “change the priceafter several more units have been sold” is changed each time theproduct is sold. Therefore, information concerning the number of retailsales units must be acquired from the retail sales history table 25.Further, when the policy PO as defined is for the changing of the priceas time elapses, the condition “change the price several minutes (orseveral hours or several days) from now”, or the condition “change theprice at a specific hour (or on a specific date)” is changed to reflecteach predetermined time. Therefore, the time information must beobtained from the system.

[0099] In this manner, required information is acquired in accordancewith the contents of the policy PO. Further, all the information that itseems may be used for the determination may be obtained, but onlynecessary information may be employed in consonance with the contents ofthe policy PO.

[0100] The obtained information is employed to determine whether theupdating of the price trend table 24 is required (step 1104). That is, acheck is performed to determine whether the information obtained at step1102 satisfies the change condition C obtained from the price trendtable 24. When the information does not satisfy the condition, e.g., ifthe policy PO for changing the price in accordance with the number ofretail sales units is defined and the number of retail sales units is 0,the processing is terminated without updating the price trend table 24(step 1105).

[0101] When the information obtained at step 1102 satisfies the changecondition C acquired from the price trend table 24, e.g., when thepolicy PO establishes that a price in accordance with the number ofunits purchased and when the number of purchases is equal to or greaterthan one, the price trend table 24 is updated in accordance with thepolicy PO (steps 1105 and 1106).

[0102] When the price trend update module 14 is activated upon thereceipt of the inquiry from the acceptance module 11, the price trendupdate module 14 transmits, to the acceptance module 11, a responsestating whether the price trend table 24 has been changed and includingthe results obtained by changing the price trend table 24 (step 1107).

[0103] As is described above, since the price trend update module 14 isoperated in the same way as is the price update module 13, and is alsoactivated when the acceptance module 11 has received a request forproduct information, the latest information can always be stored in theprice trend table 24.

[0104] In this embodiment, the price trend update module 14 has beenactivated not only upon the receipt of the inquiry from the acceptancemodule 11, but also by being called by the price update module 13.However, the price trend update module 14 may be operated separatelyfrom the price update module 13. For example, when the policy forchanging the price of the product as time elapses is defined in theprice determination policy table 22, information concerning the trendassociated with the changing of the price is varied, as needed.

[0105] Therefore, it is preferable that, in order to update the pricetrend table 24, the price trend update module 14 be operated morefrequently than the price update module 13.

[0106]FIG. 12 is a diagram showing an example input screen displayed bythe user terminal 30. In an input screen 40, music provided as digitalcontent is defined as a product, and the price is to be changed inaccordance with the number of purchases (the number of downloads).

[0107] As is described above, when a product information request isissued by the user terminal 30 to the product retail sales managementserver 10, the acceptance module 11 of the product retail salesmanagement server 10 prepares the input screen 40, and transmits thefile for the input screen 40 to the user terminal 30. The user terminal30 then uses a browser to display the input screen 40, and waits for theinput of data by a user.

[0108] In FIG. 12, the input screen 40 includes a product informationdisplay column 41, for displaying information concerning a product, aprice display column 42, for displaying the price of the product, aprice trend display column 43, for indicating the trend associated withthe changing of the price, and a purchase button 44, for transmitting apurchase determination command. In the example in FIG. 12, music pieces1 to 3, recorded by a singer A, and music pieces 1 to 3, recorded by asinger B, are displayed as product information and are presented in theproduct information display column 41, while the prices of theindividual music pieces are displayed in the price display column 42.Further, the number of purchases (the number of downloads) remaininguntil the product price is next raised is displayed in the price trenddisplay column 43. This value, together with a message at the bottom ofthe input screen 40, “raise the price 10 yen every 20 downloads”,represents the price change trend. That is, the user understands thatwhen the number of product information downloads equals the numberdisplayed in the price trend display column 43, the download count willreach 20 and the price of the product will be raised 10 yen.

[0109] When the user selects a desired music piece (a product) on theinput screen 40 and clicks on the purchase button 44, the purchasedetermination command is transmitted to the product retail salesmanagement server 10. Further, if needed, when the purchase button 44 isclicked on, a purchase procedures screen may be displayed and the userrequested to enter his or her name and address and to select a paymentmethod. When a predetermined time has elapsed between the time the inputscreen 40 was displayed and the purchase button 44 was clicked on,instead of the transmission of the purchase determination command, amessage may be displayed requesting the provision of the latestinformation for the price and the price change trends, and the data onthe input screen 40 may be updated.

[0110]FIG. 13 is a diagram showing the state of the input screen 40 whena predetermined time has elapsed since the state shown in FIG. 12 wasacquired.

[0111] In FIG. 13, the prices for the individual music pieces and theprice change trends (information indicating the remaining download countbefore the price is raised) are changed. For example, it is apparentthat music piece 1, recorded by singer A, has been downloaded 15 times,and that the price will be raised after another five downloads.Similarly, it is apparent that after the price of the music piece 2,recorded by singer A was raised five times (the music piece 2 wasdownloaded 100 (=20×5) times), the music piece 2 was downloaded ten moretimes, and its price will be raised to 140 yen after another tendownloads. In this manner, more profits can be obtained with a popular,good selling product by raising its price, and a competitive price canbe provided for a poor selling product by reducing its price.

[0112] The input screen 40 shown in FIG. 12 and 13 is merely an example,and so long as the same data entry is available, the structure is notlimited to the one shown. For example, the purchase button 44 may not beprovided and the screen may be shifted to a purchase procedure screen byclicking on a desired music piece. Or, a script may be written in theinput screen file, so that the price of the product or the price changetrends can be automatically updated.

[0113] The information presented in the product information displaycolumn 41 should also be appropriately displayed in accordance with thekind of product. For example, if the product is not digital content butan article, an image of the article or an introductory statement for thearticle may be provided.

[0114] A specific operation performed for this embodiment will now bedescribed. FIG. 14 is a diagram showing the initial state of each tableprepared for a predetermined product. Since the price of a product ischanged without depending on the rankings, the ranking table 26 is notpresent. It should be noted that in FIG. 14 the formats shown in FIG. 3to 7 are not employed for the respective tables and that only brieflistings of the contents are displayed.

[0115] In FIG. 14, in the initial setup table 21, the number of units(Deal Count) of the product (Product ID 01) purchased is set as thedependency element (Dependency_(—)1). In the price determination policytable 22, the number of units (Up counter_C) that must be purchased toraise the price is set at 20, and the price rise range (Up Range_C) isset at 10 yen. In the current price table 23, the initial value of theretail price (Price) is set at 1000 yen. In the price trend table 24,the number of remaining units that must be purchased before the pricerise (Rest_C) is initially set to 20. The retail sales history table 25is set to Null because the sale of the product has not yet begun.

[0116] Assume that one purchaser bought one product (Product ID 01) atpredetermined time (11:00). FIG. 15 is a diagram showing a table whereinthe contents are changed by this purchase.

[0117] In FIG. 15, the retail sales history table 25 records 11:00(written as T(11:00)) as the purchase time (Purchase Time) of theproduct (Product ID 01), and records 1000 yen as the purchase price(Purchase Price). Accordingly, as is shown in FIG. 10, the price updatemodule 13 is operated and whether the current price table 23 must beupdated is determined. In this example, since the number of units (UpCounter_C) required to raise the price in the price determination policytable 22 is set at 20, and the number of remaining units (Rest_C) beforethe price is raised in the price trend table 24 is set at 20, no pricechange is performed.

[0118] The price trend update module 14 is operated and whether theprice trend table 24 must be updated is determined. But since oneproduct (Product ID 01) unit has been purchased, the price trend table24 is updated, and the number of units remaining before the price israised is decremented by one, to 19.

[0119] Assume that a predetermined time has elapsed (11:30) and thetotal number of purchased product (Product ID 01) units has reached 20.FIG. 16 is a diagram showing a table in which the contents areaccordingly changed.

[0120] In FIG. 16, the retail sales history table 25 records 11:30(written as T(11:30)) as the purchase time (Purchase Time) of theproduct (Product ID 01), and records 1000 yen as the purchase price(Purchase Price). Accordingly, as is shown in FIG. 10, the price updatemodule 13 is operated and whether the current price table 23 must beupdated is determined. In this example, since the number of unitspurchased reaches 20, that is the number of units (Up Counter_C)required to raise the price in the price determination policy table 22,and the number of remaining units (Rest_C) before the price is raised inthe price trend table 24 is reduced to 0. Thus, the current price table23 is updated and the retail price of the product (Product ID 01) ischanged. Since the range (Up Range_C) of the price rise in the Pricedetermination policy table 22 is 10 yen, the retail price (Price) in thecurrent price table 23 is increased 10 yen to 1010 yen. Therefore, theproduct (Product ID 01) is thereinafter purchased at 1010 yen.

[0121] The price trend update module 14 is operated and whether theprice trend table 24 need be updated is determined. In this example, theprice trend table 24 is also updated based on the updating of thecurrent price table 23. Specifically, since this occurs immediatelyafter the current price table 23 is updated by the price update module13 and the new retail price is obtained, the number of units (UpCounter_C) required to increase the price in the price determinationpolicy table 22 is again set to 20.

[0122] Another example operation for this embodiment will now bedescribed.

[0123]FIG. 17 is a diagram showing the initial states of the tablesconcerning a predetermined product. In this example, since the price ofthe product is changed without depending on its rank, the ranking table26 is not present. It should be noted that in FIG. 14 the formats shownin

[0124]FIG. 3 to 7 are not employed for the respective tables and theonly brief listings of the contents displayed.

[0125] In this example, the price update module 13 and the price trendupdate module 14 are activated every ten minutes to determine whetherthe current price table 23 and the price trend table 24 must be updated.

[0126] In FIG. 17, in the initial setup table 21, the number of units(Deal Count) of the product (Product ID 01) that are purchased is set asthe dependency element (Dependency_(—)1). In the price determinationpolicy table 22, the number of units (Up counter_C) that must bepurchased to raise the price is set at 20, and the price rise range (UpRange_C) is set at 10 yen. Further, in this example, when there havebeen no product (Product ID 01) purchases for a predetermined period oftime, the retail price of the product is reduced. Thus, in the pricedetermination policy 22, the time defined as the price reductioncondition (Time Limit_C) is 7200 seconds, and the range of a pricereduction (Down Range_C) is set at 10 yen.

[0127] In the current price table 23, the initial value of the retailprice (Price) is set at 1000 yen. In the price trend table 24, thenumber of units remaining to be purchased before a price rise (Rest_C)is initially set to 20. The last access time (Last Access_C), i.e., thetime whereat the count is initially began, is set at 10:00 (written asT(10:00)). And the retail sales history table is set to Null because thesale of the product is not yet begun.

[0128] After 10:00, the product retail sales management server 10activates the price update module 13 and the price trend update module14 every 10 minutes to permit them to determine whether the updating ofthe tables is necessary. However, because in each case the time elapsedsince the price trend table 24 was last accessed (Last Access_C) is lessthan 7200 seconds, which is the price reduction condition in the pricedetermination policy table 22, neither the current price table 23 northe price trend table 24 are updated.

[0129] Assume that one purchaser bought one product (Product ID 01) at apredetermined time (11:00). FIG. 18 is a diagram showing tables whereinthe contents are changed by this purchase.

[0130] In FIG. 18, the retail sales history table 25 records 11:00(written as T(11:00)) as the purchase time (Purchase Time) of theproduct (Product ID 01), and records 1000 yen as the purchase price(Purchase Price). Accordingly, the price update module 13 is operatedand whether the current price table 23 must be updated is determined. Inthis example, since the number of units (Up Counter_C) required to raisethe price in the price determination policy table 22 is set at 20, andthe number of remaining units (Rest_C) before the price will be raisedin the price trend table 24 is set at 20, no price change is performed.

[0131] Thereafter the price trend update module 14 is operated andwhether the price trend table 24 must be updated is determined. Sinceone product (Product ID 01) unit has been purchased, the price trendtable 24 is updated, and the number of units remaining before the priceis raised is decremented by one, to 19, and 11:00 (T(11:00)) is set asthe last access time (Last Access_C).

[0132] Assume that thereafter the product (Product ID 01) is notpurchased for 7200 seconds (two hours). Then,

(T(Current Time)−Last Access_(—) C)≧(Time Limit_(—) C)

[0133] is established, and thus, the price update module 13 and theprice trend update module 14 update the current price table 23 and theprice trend table 24. FIG. 19 is a diagram showing the tables after thecontents have been accordingly changed.

[0134] In FIG. 19, first, since the range (Down Range_C) of the pricereduction in the price determination policy table 22 is 10 yen, theretail price (Price) in the current price table 23 is reduced by 10 yento 990 yen. Thus, the product (Product ID 01) can thereafter bepurchased at 990 yen.

[0135] Since the current price table 23 has just been updated by theprice update module 13 and a new retail price has just been obtained,the price trend update module 14 again set to 20, the number of units(Up Counter_C) that are required to be purchased for the price in theprice determination policy table 22 to be raised. Further, in order tocount the time again, the last access time (Last Access_C) is set to thecurrent time (written as T(Current Time)), i.e., 13:00.

[0136] As is described above, the retail price of the product can bedynamically changed in accordance with the retail sales state of theproduct, and an appropriate retail price can be set in accordance withthe reaction of the market.

[0137] As is described above, according to the present invention, aretail sales management system can be provided that dynamically sets theretail price for a product or a service in accordance with thepopularity or an evaluation of the product or the service.

[0138] A legend for the symbols is repeated herein for convenience:

[0139]10: Product retail sales management server

[0140]11: Acceptance module

[0141]12: Retail sales management module

[0142]13: Price update module

[0143]14: Price trend update module

[0144]20: Database

[0145]21: Initial setup table

[0146]22: Price determination policy table

[0147]23: Current price table

[0148]24: Price trend table

[0149]25: Retail sales history table

[0150]26: Ranking table

[0151]30: User terminal

[0152]40: Input screen

[0153] Having described embodiments of the invention it is noted thatmodifications and variations can be made by persons skilled in the artin light of the above teachings. It is therefore to be understood thatchanges may be made in the particular embodiments of the inventiondisclosed which are within the scope and spirit of the invention asdefined by the appended claims. Having thus described the invention withthe details and particularity required by the patent laws, what isclaims and desired protected by Letters Patent is set for in theappended claims.

What is claimed is:
 1. A server for managing the retail sales of aproduct across a communication network comprising: retail sales statemanagement means for managing the retail sales state of said product;price setting means for dynamically setting the price of said product inaccordance with rules and the retail sales state of said product and inaccordance with the actual retail sales status of said product whenmanaged by said retail sales state management means; and productinformation provision means for, upon the receipt of an informationrequest via said communication network, furnishing a requesttransmission source with the information concerning said product andsaid price of said product, set by said price setting means at the timesaid information request is received.
 2. The server according to claim1, further comprising: price trend information provision means forgenerating, in accordance with said actual retail sales state of saidproduct, information concerning trends affecting the changes of saidprice of said product, and for furnishing said information to saidinformation request transmission source.
 3. The server according toclaim 1, wherein said price setting means can set a price for saidproduct by using rules, based on said retail sales state of saidproduct, according to which the price is increased as the number ofproduct units sold rises or decreased as the number of product unitssold falls.
 4. A server for managing the retail sales of a productacross a communication network comprising: retail sales state managementmeans for managing the retail sales state of said product; and pricesetting means for dynamically setting the price of said product inaccordance with rules and the retail sales state of said product and inaccordance with the actual retail sales status of said product whenmanaged by said retail sales state management means.
 5. A server forcharging for and providing digital content via a communication networkcomprising: sales state management means, for managing the sales stateof said digital content; price setting means, for dynamically changing acharge for accessing said digital content in accordance with rules andthe sales state of said digital content and in accordance with saidsales state of said digital content, which is managed by said salesstate management means; and information provision means for presentingto an information request transmission source, upon the receipt of aninformation request via said communication network, informationconcerning said digital content and said charge for accessing saiddigital content that is set by said price setting means at the time saidinformation request is received.
 6. The server according to claim 5,further comprising: price trend information provision means, forgenerating, in accordance with said sales state of said digital content,information concerning trends affecting the changing of said charge foraccessing said digital content and for furnishing said information tosaid information request transmission source.
 7. The server according toclaim 5, wherein said price setting means sets said charge for accessingsaid digital content in accordance with rules and said sales state ofsaid digital content and according to which said charge for an access isincreased when the number of accesses of said digital content rises oris reduced when the number of accesses falls.
 8. The server according toclaim 5, wherein said price setting means sets said charge for accessingsaid digital content in accordance with rules, which is based on saidsales state of said digital content, according to which said charge foran access is increased when the rank awarded said digital content, whichis consonant with the popularity or the evaluation of said digitalcontent, is incremented, or said charge for an access is reduced whensaid rank awarded said digital content is decremented.
 9. A server forcharging for and providing a digital content via a communication networkcomprising: sales state management means, for managing the sales stateof said digital content; and price setting means, for dynamicallychanging a charge for accessing said digital content in accordance withrules and the sales state of said digital content and in accordance withsaid actual sales state of said digital content, which is managed bysaid sales state management means.
 10. An information communicationterminal, for accessing a product retail sales management server acrossa communication network and for purchasing a product offered by saidserver, whereby an information request is issued to said server in orderto obtain information concerning said product and the price of saidproduct; whereby said information concerning said product and said priceof said product, and information concerning trends affecting the changesof said price are received after said server has accepted saidinformation request; and whereby, when a user has examined saidinformation, as needed, and has determined to purchase said product, apurchase request to that effect is transmitted to said server.
 11. Aproduct retail sales management method, for managing the retail sales ofa product in accordance with a purchase request that is issued, via acommunication network, by a server connected thereto, comprising thesteps of: managing the retail sales state of said product; dynamicallysetting the price of said product in accordance with rules and theretail sales state of said product and in accordance with the actualretail sales status of said product; furnishing information concerningsaid product upon the receipt of an information request via saidcommunication network, and furnishing said price set for said product atthe time said information request is accepted; and accepting a purchaserequest for said product that is issued after said informationconcerning said product and said price of said product have beenprovided.
 12. The product retail sales management method according toclaim 11, further comprising the steps of: generating, upon receipt ofsaid information request, information concerning trends affecting thechanges of said price of said product in accordance with said retailsales state of said product, wherein, at said step of furnishing saidinformation concerning said product and said price of said product, saidinformation concerning said trends affecting the changes of said priceof said product is also furnished.
 13. A product retail sales managementmethod, for managing the retail sales of a product in accordance with apurchase request that is issued, via a communication network, by aserver connected thereto, comprising the steps of: managing the retailsales state of said product; dynamically setting the price of saidproduct in accordance with rules and the retail sales state of saidproduct and in accordance with the actual retail sales status of saidproduct; and furnishing information concerning said product upon thereceipt of an information request via said communication network, andfurnishing said price set for said product at the time said informationrequest is accepted.
 14. A storage medium on which input means of acomputer stores a computer-readable program that permits said computerto perform: a process for managing the retail sales state of saidproduct; a process for dynamically setting the price of said product inaccordance with rules and the retail sales state of said product and inaccordance with the actual retail sales status of said product; aprocess for furnishing information concerning said product upon thereceipt of an information request via said communication network, andfurnishing said price set for said product at the time said informationrequest is accepted; and a process for accepting a purchase request forsaid product that is issued after said information concerning saidproduct and said price of said product have been provided.
 15. Thestorage medium according to claim 14, wherein said program generates,upon receipt of said information request, information concerning trendsaffecting the changes of said price of said product in accordance withsaid retail sales state of said product; and wherein, in said processfor furnishing said information concerning said product and said priceof said product, said program furnishes said information concerning saidtrends affecting the changes of said price of said product.
 16. Aprogram transmission apparatus comprising: storage means for storing aprogram that permits a computer to perform a process for managing theretail sales state of said product, a process for dynamically settingthe price of said product in accordance with rules and the retail salesstate of said product and in accordance with the actual retail salesstatus of said product, a process for furnishing information concerningsaid product upon the receipt of an information request via saidcommunication network, and furnishing said price set for said product atthe time said information request is accepted, and a process foraccepting a purchase request for said product that is issued after saidinformation concerning said product and said price of said product havebeen provided; and transmission means for reading said program from saidstorage means and for transmitting said program.